Signed-off-by: Peter Atashian <retep998@gmail.com>

Add check to ensure trait bounds are only placed on
ty_param

This warning has been around in the compiler for quite some time now, but the
real place for a warning like this, if it should exist, is in Cargo, not in the
compiler itself. It's a first-class feature of Cargo that multiple versions of a
crate can be compiled into the same executable, and we shouldn't be warning
about our first-class features.

…:Item`)

This warning has been around in the compiler for quite some time now, but the
real place for a warning like this, if it should exist, is in Cargo, not in the
compiler itself. It's a first-class feature of Cargo that multiple versions of a
crate can be compiled into the same executable, and we shouldn't be warning
about our first-class features.

This commit takes a first pass at stabilizing `std::thread`:

* It removes the `detach` method in favor of two constructors -- `spawn`
  for detached threads, `scoped` for "scoped" (i.e., must-join)
  threads. This addresses some of the surprise/frustrating debug
  sessions with the previous API, in which `spawn` produced a guard that
  on destruction joined the thread (unless `detach` was called).

  The reason to have the division in part is that `Send` will soon not
  imply `'static`, which means that `scoped` thread creation can take a
  closure over *shared stack data* of the parent thread. On the other
  hand, this means that the parent must not pop the relevant stack
  frames while the child thread is running. The `JoinGuard` is used to
  prevent this from happening by joining on drop (if you have not
  already explicitly `join`ed.) The APIs around `scoped` are
  future-proofed for the `Send` changes by taking an additional lifetime
  parameter. With the current definition of `Send`, this is forced to be
  `'static`, but when `Send` changes these APIs will gain their full
  flexibility immediately.

  Threads that are `spawn`ed, on the other hand, are detached from the
  start and do not yield an RAII guard.

  The hope is that, by making `scoped` an explicit opt-in with a very
  suggestive name, it will be drastically less likely to be caught by a
  surprising deadlock due to an implicit join at the end of a scope.

* The module itself is marked stable.

* Existing methods other than `spawn` and `scoped` are marked stable.

The migration path is:

```rust
Thread::spawn(f).detached()
```

becomes

```rust
Thread::spawn(f)
```

while

```rust
let res = Thread::spawn(f);
res.join()
```

becomes

```rust
let res = Thread::scoped(f);
res.join()
```

[breaking-change]

This commit is a first past stabilization of `std::error`:

* The module is stable.
* The `FromError` trait and impls are stable
* The `Error` trait itself is left unstable, pending current APIs and
  possible revisions during the alpha cycle.

Believe or not, `CreateProcess()` is racy if several threads create
child processes: [0], [1], [2].

This caused some tests show crash dialogs during
`make check-stage#-rpass`.

More explanation:

On Windows, `SetErrorMode()` controls display of error dialogs: it
accepts new error mode and returns old error mode.
The error mode is process-global and automatically inherited to child
process when created.

MSYS2 bash shell internally sets it to not show error dialogs, therefore
`make check-stage#-rpass` should not show them either.

However, [1] says that `CreateProcess()` internally invokes
`SetErrorMode()` twice: at first it sets mode `0x8001` and saves
original mode, and at second it restores original mode.
So if two threads simultaneously call `CreateProcess()`, the first
thread sets error mode to `0x8001` then the second thread recognizes
that current error mode is `0x8001`. Therefore, The second thread will
create process with wrong error mode.

This really occurs inside `compiletest`: it creates several processes on
each thread, so some `run-pass` tests are invoked with wrong error mode
therefore show crash dialog.

This commit adds `StaticMutex` for `CreateProcess()` call. This seems
to fix the "dialog annoyance" issue.

[0]: http://support.microsoft.com/kb/315939
[1]: https://code.google.com/p/nativeclient/issues/detail?id=2968
[2]: https://ghc.haskell.org/trac/ghc/ticket/2650

Both FreeBSD and DragonFly define pthread_key_t as int, while Linux
defines it as uint. As pthread_key_t is used as an opaque type and
storage size of both int and uint are the same, this is rather a
cosmetic change.

iOS uses ulong (as OS X) so difference is critical on 64bit platforms.

…ed out to be that were being very loose with bound regions in trans (we were basically just ignoring and flattening binders). Since binders are significant to subtyping and hence to trait selection, this can cause a lot of problems. So this patch makes us treat them more strictly -- for example, we propagate binders, and avoid skipping past the `Binder` by writing `foo.0`.

Fixes rust-lang#20644.

There's been some debate over the precise form that these APIs should take, and
they've undergone some changes recently, so these APIs are going to be left
unstable for now to be fleshed out during the next release cycle.

[breaking-change]

Conflicts:
	src/libcollections/lib.rs
	src/librustc/lib.rs
	src/libserialize/lib.rs
	src/libstd/lib.rs

Conflicts:
	src/libcore/array.rs
	src/libcore/cell.rs
	src/libcore/prelude.rs
	src/libstd/path/posix.rs
	src/libstd/prelude/v1.rs
	src/test/compile-fail/dst-sized-trait-param.rs

Conflicts:
	src/libsyntax/parse/parser.rs

This commit takes a first pass at stabilizing `std::thread`:

* It removes the `detach` method in favor of two constructors -- `spawn`
  for detached threads, `scoped` for "scoped" (i.e., must-join)
  threads. This addresses some of the surprise/frustrating debug
  sessions with the previous API, in which `spawn` produced a guard that
  on destruction joined the thread (unless `detach` was called).

  The reason to have the division in part is that `Send` will soon not
  imply `'static`, which means that `scoped` thread creation can take a
  closure over *shared stack data* of the parent thread. On the other
  hand, this means that the parent must not pop the relevant stack
  frames while the child thread is running. The `JoinGuard` is used to
  prevent this from happening by joining on drop (if you have not
  already explicitly `join`ed.) The APIs around `scoped` are
  future-proofed for the `Send` changes by taking an additional lifetime
  parameter. With the current definition of `Send`, this is forced to be
  `'static`, but when `Send` changes these APIs will gain their full
  flexibility immediately.

  Threads that are `spawn`ed, on the other hand, are detached from the
  start and do not yield an RAII guard.

  The hope is that, by making `scoped` an explicit opt-in with a very
  suggestive name, it will be drastically less likely to be caught by a
  surprising deadlock due to an implicit join at the end of a scope.

* The module itself is marked stable.

* Existing methods other than `spawn` and `scoped` are marked stable.

The migration path is:

```rust
Thread::spawn(f).detached()
```

becomes

```rust
Thread::spawn(f)
```

while

```rust
let res = Thread::spawn(f);
res.join()
```

becomes

```rust
let res = Thread::scoped(f);
res.join()
```

[breaking-change]

Believe or not, `CreateProcess()` is racy if several threads create
child processes: [0], [1], [2].

This caused some tests show crash dialogs during
`make check-stage#-rpass`.

More explanation:

On Windows, `SetErrorMode()` controls display of error dialogs: it
accepts new error mode and returns old error mode.
The error mode is process-global and automatically inherited to child
process when created.

MSYS2 bash shell internally sets it to not show error dialogs, therefore
`make check-stage#-rpass` should not show them either.

However, [1] says that `CreateProcess()` internally invokes
`SetErrorMode()` twice: at first it sets mode `0x8001` and saves
original mode, and at second it restores original mode.
So if two threads simultaneously call `CreateProcess()`, the first
thread sets error mode to `0x8001` then the second thread recognizes
that current error mode is `0x8001`. Therefore, The second thread will
create process with wrong error mode.

This really occurs inside `compiletest`: it creates several processes on
each thread, so some `run-pass` tests are invoked with wrong error mode
therefore show crash dialog.

This commit adds `StaticMutex` for `CreateProcess()` call. This seems
to fix the "dialog annoyance" issue.

[0]: http://support.microsoft.com/kb/315939
[1]: https://code.google.com/p/nativeclient/issues/detail?id=2968
[2]: https://ghc.haskell.org/trac/ghc/ticket/2650

This bound is probably unintentional and is unnecessarily
constricting.

This reverts commit 2404232.

Conflicts:
	src/libcore/intrinsics.rs